1. Field of the Invention
This invention relates generally to computer networking, and more particularly to a common hardware interface for communication within a Fibre Channel network environment.
2. Description of the Related Art
Conventionally, to provide an interface to hardware devices, software designers often utilize device drivers designed for specific hardware devices. A device driver is a named entity that supports basic I/O functions, such as read, write, get configuration, and set configuration, and typically, also uses and manages interrupts from a device as well.
A device driver is used to provide access to a device from application code in as general purpose a fashion as reasonable, while being as efficient as possible. The interface for a device driver typically is generic and device driver independent, however, the actual driver implementation is completely up to the device driver designer.
As mentioned above, most device drivers are concerned with the movement of information, for example data bytes along a serial interface, or packets in a network. Interrupts typically are used in order to make the most efficient use of system resources, which allows for other application processing to take place while the data transfers are underway, with the interrupts used to indicate when various events have occurred.
For example, a serial port typically generates an interrupt after a character has been sent xe2x80x9cdown the wirexe2x80x9d and the interface is ready for another. While the data is being sent, further application processing should be allowed since the data transfer can take quite a long time. To allow further application processing, an interrupt is generally used to xe2x80x9calertxe2x80x9d the driver and allow the driver to send a new character as soon as the current one is complete, without any active participation by the application code.
One of the first storage and interconnect technologies to utilize device drivers was the Small Computer Systems Interface (SCSI), which is an intelligent, parallel I/O bus on which various peripheral devices and controllers exchange information. Because of its longevity in the marketplace, the parallel SCSI provides a large depth and breadth of products, which include SCSI disk drives, CD-ROM, RAID subsystems, scanners, and other products that are available from a multitude of sources.
To obtain the benefits of the SCSI I/O performance, computer systems use SCSI controllers. A SCSI controller is a hardware device that provides communication with a SCSI network. Communication with the SCSI controller generally is accomplished using a SCSI device driver.
FIG. 1 is a block diagram showing a prior art SCSI system 100. The SCSI system 100 includes an application program 102, a SCSI controller 108, SCSI drives 110, and a SCSI device driver comprising an operating system module (OSM) 104 and a common hardware interface module (CHIM) 106. As explained in greater detail subsequently, typically the OSM is operating system dependent, while the CHIM is operating system independent.
During operation the application program 102 executes on a particular operating system, such as WINDOWS 95, and accesses networked SCSI devices, such as the SCSI drives 110, using the SCSI device driver. Specifically, when the application program 102 requires access to a SCSI device, such as the SCSI drives 110, the application program 102 passes a device access command to the SCSI device driver via the OSM 104 section of the SCSI device driver.
Since the OSM 104 is operating system dependent, the OSM 104 varies depending on the type of operating system the application 102 is executing on. Hence, to use the OSM 104 in combination with an application 102 executing on a NT4.0 operating system, the OSM should be designed specifically for the NT4.0 operating system. As shown in FIG. 1, the OSM 104 can be designed as a NT4.0 OSM 112, a WINDOWS 95 OSM 114, a Linux OSM 116, a VX Work OSM 118, a MAC OSM 120, or any other operating system OSM. In this example, since the application 102 is executing on a WINDOWS 95 operating system, the OSM 104 would actually be a WINDOWS 95 OSM 114.
When the OSM 104 receives the operating system specific device access command, the OSM 104 translates the command into an operating system independent CHIM device access command for the common hardware interface module (CHIM) 106 portion of the SCSI device driver, and passes the translated command to the CHIM 106.
Thus, an OSM 104 is written for a specific operating system and completely isolates the CHIM 106 from the host operating system. Typically, the OSM 104 presents device driver entry points that are specific to the particular operating system and converts them to operating system independent calls to the CHIM 106. Thus, when the operating system calls the driver""s initialization entry points, the OSM 104 makes a series of calls to the CHIM 106 that allow the CHIM 106 to check for the presence of adapter hardware, initialize the adapter, and access connected devices.
The CHIM 106 is an operating system independent common hardware interface module that receives CHIM commands and translates the CHIM commands into commands for the SCSI controller 108.
Whereas the OSM 104 isolates the CHIM 106 from the operating system, the CHIM 106 isolates the OSM 104 from the SCSI controller 108 hardware. The CHIM 106 initializes the SCSI controller 108 hardware, builds commands in the correct format for the adapter, and performs command delivery.
In use, The OSM 104 provides a protocol-specific command, such as a SCSI Command Descriptor Block (CDB), to the CHIM 106. After receiving the command from the CHIM 106, the SCSI controller 108 accesses the SCSI drives 110 using the SCSI protocol.
The problem with the prior art SCSI system 100 is that SCSI protocol is often not fast enough to support many modem application needs. The limitations for SCSI in terms of bus speed, reliability, cost, and device count are leading systems and storage designers to look toward serial device interfaces that feature higher data transfer rates.
One such serial device interface is Fibre Channel, which provides a high-speed data transfer interface that can be used to connect systems and storage in point-to-point, switched, or Loop topologies. In addition, the Fibre Channel Arbitrated Loop can support copper media and loops having 126 devices, or nodes.
FIG. 2 is a block diagram illustrating a conventional Fibre Channel system 200. The Fibre Channel system 200 includes a Port Driver 202, a Fibre Channel driver 204, a Fibre Channel controller 206, and a network device 208. In use, the port driver passes device access commands to the Fibre Channel driver 204, which facilitates communication between the port driver 202 and the Fibre Channel controller 206.
The Fibre Channel driver 204 operates similar to the device drivers discussed previously. Broadly speaking, the Fibre Channel driver 204 provides access to the Fibre Channel controller 206 in as general purpose a fashion as reasonable while being as efficient as possible. Generally, the Fibre Channel controller 206 accesses the network device 208 using a Fibre Channel protocol.
In a Fibre Channel Arbitrated Loop configuration, when a device is ready to transmit data, the device initially arbitrates and gains control of the Loop. Typically, the device accomplishes this by transmitting an Arbitrate (ARBx) Primitive Signal, where x=the Arbitrated Loop Physical Address (AL_PA) of the device. Once a device receives its own ARBx Primitive Signal, the device has gained control of the Loop and can then communicate with other devices by transmitting an Open (OPN) Primitive Signal to a destination device. Once this happens, there essentially exists point-to-point communication between devices.
If more than one device on the Loop is arbitrating at the same time, the x values of the ARB Primitive Signals are compared. When an arbitrating device receives another device""s ARBx, the ARBx with the numerically lower AL_PA is forwarded, while the ARBx with the numerically higher AL_PA is blocked. Thus, the device with the lower AL_PA generally gains control of the Loop first. Then, once the device relinquishes control of the Loop, the other device can gain control of the Loop.
Unlike token-passing schemes, there generally is no limit on how long a device may retain control of the Loop. This demonstrates the xe2x80x9cchannelxe2x80x9d aspect of Fibre Channel. There is, however, an optional Access Fairness Algorithm, which prohibits a device from arbitrating again until all other devices have had a chance to arbitrate.
In addition to Fibre Channel""s strong channel characteristics, Fibre Channel also provides powerful networking capabilities, allowing switches and hubs to enable the interconnection of systems and storage into tightly-knit clusters. These clusters are capable of providing high levels of performance for file service, database management, or general purpose computing. Moreover, because Fibre Channel is able to span 10 kilometers between nodes, Fibre Channel allows the very high speed movement of data between systems that are greatly separated from one another.
Because of Fibre Channel""s superior performance and networking capabilities, and Fibre Channel""s broad industry support, Fibre Channel is in great demand. However, one problem with Fibre Channel is that many networks are currently configured for use with a SCSI protocol. Thus, in addition to physical connections, the overlying network software typically must be replaced to convert these networks to Fibre Channel. However, the cost of designing a completely new software system and replacing old software systems is tremendous.
In addition, development of new drivers can introduce additional programming errors, resulting in increased development time. Further, because conventional driver code often must be completely re-compiled to generate the new driver, development time is further increased. Moreover, since different software teams may create the different code modules of the driver, global variable values may be corrupted or skipped altogether.
In view of the forgoing, there is a need for a Fibre Channel interfacing system that is capable of being incorporated into existing SCSI software networks with little additional cost. The system should allow for decreased development time, and reduce problems associated with modular development.
Broadly speaking, the present invention fills these needs by providing a layer structure for configuring a Fibre Channel driver. In one embodiment, the layer structure includes a hardware layer directory that includes code for communicating with a Fibre Channel controller. In addition, a wrapper layer directory is included in the layer structure. The wrapper layer directory includes code for communicating with the code associated with the hardware layer directory, and also includes a wrapper header file that defines a particular value setting in a first state, such as a compiler directive set a particular value. The layer structure further includes a global header directory that defines a group of value settings. The group of value settings is defined for the code associated with each of the hardware directory and the wrapper layer directory. The particular value setting in the first state is also included in the group of value settings. The code associated with each of the hardware layer directory, the wrapper layer directory and the global header directory is linked with one another. The linking is accomplished such that any change to the particular value setting made in the code associated with the wrapper layer directory has priority over the first state defined in the global header directory. Thus, value definitions in lower level directories take precedence over the value definitions in the global header directory. In this manner, default values may be provided in the global header directory that can be overridden when needed by the developer.
In another embodiment, a method for configuring a Fibre Channel driver is disclosed. The method begins by defining a hardware layer directory that includes code for communicating with a Fibre Channel controller. A wrapper layer directory is also created that includes code for communicating with the code associated with the hardware layer directory. Preferably, the wrapper layer directory also includes a wrapper header file that defines a particular value setting in a first state. In addition, a global header directory is provided that defines a group of value settings that define settings for the code associated with each of the hardware directory and the wrapper layer directory. Further, the group of value settings includes the particular value setting in the first state. The code associated with each of the hardware layer directory, the wrapper layer directory and the global header directory is linked with one another such that changes to the particular value setting, for example to a second state, made by code associated with the wrapper layer directory are prioritized.
In a further embodiment, a system for configuring a Fibre Channel driver is disclosed. The system includes a software code compiler and an object file linker. The system further includes a hardware layer directory that includes code for communicating with a Fibre Channel controller, and a wrapper layer directory that includes code for communicating with the code associated with the hardware layer directory. The wrapper layer directory preferably also includes a wrapper header file that defines a particular value setting in a first state. A global header directory is also included in the system that defines a group of value settings. The group of value settings are defined for the code associated with each of the hardware directory and the wrapper layer directory, and preferably include the particular value setting in the first state. The system also includes logic that prioritizes a change to the particular value setting to a second state in code associated with the wrapper layer directory over the first state of the global header directory.
Advantageously, the layer structure of the present invention allows for isolation of programming errors resulting from new code additions, and decreases compiling time by reducing the amount of code that must be compiled to upgrade the Fibre Channel driver.
The layer structure further allows the driver developer to provide default values for variables used in other code segments by allowing variables defined at lower levels of the layer structure to take precedence over the same variables defined at higher levels of the layer structure. Thus, a variable defined in a Fibre Channel Common Hardware Interface Module (FCHIM) header file will supersede the variable definition in a header file in the global header directory, including value assignments to the variable.
Other aspects and advantages of the invention will become apparent from the following detailed description, taken in conjunction with the accompanying drawings, illustrating by way of example the principles of the invention.